1. Field of the Art
The present invention relates generally to shared resource allocation in a multi-user networking environment, and more particularly, to a system providing opportunistic file access control over shared resources in a multi-user networking environment.
2. Discussion of the Related Art
A typical computer networking system consists of a number of individual nodes, including at least one server node and two or more client nodes, interconnected through a network link. Broadly, the server manages resources directed for shared usage among a number of clients on the network. More specifically, a file server manages a disk or other device for storing files to be shared by various clients throughout the network.
As is known by persons of ordinary skill in the art, a bottleneck in networking environments is the network link that interconnects the nodes. The primary reason for this bottleneck is the bandwidth of the physical medium comprising the network link--whether it is twisted-pair, coax, or fiber-optic cabling--as the bandwidth determines the maximum rate that data can be communicated across the link. Reducing the number and amount of data transfers across the network link will correspondingly lessen the deleterious effects of the bottleneck and, accordingly, enhance overall network system performance.
One known way to reduce the number of network transfers is to temporarily store files retrieved from a file server in the retrieving client's local memory space, usually a cache memory. When a client requests multiple or repeated access to a file stored on a file server, that file is written into the requesting client's local cache until that client is finished with the file, at which time the file is written back to the server (if changed). In this manner, overall system performance is improved by eliminating unnecessary intermediate file transfers over the network. In the context of the present invention, and as used herein, the term "file" refers to any collection of information or data regardless of size or whether the information or data is merely a portion or subset of a larger collection of information or data, e.g. sectors, blocks, records or the like.
Problems arise, however, when two or more clients need access to the same file stored at the server, and one or more clients need read-write access to that file. To provide a simple illustration of this problem, suppose client A and client B both retrieve the same file from a server for read-write access, whereby the same file is simultaneously residing in the local caches of both client A and client B. Assume further that both clients make modifications to the file. If client A writes the file back to the server first, when client B writes the file back to the server, the changes made by client A will be destroyed. Moreover, client A will be unaware that its changes were overwritten.
The same problem, although not as obvious, can arise where multiple clients have retrieved a file into their local cache, but just one client has requested read-write access. For example, suppose that client A retrieves a file for read-write access and makes certain modifications to the file, but retains the file in its local cache for further use. At some time later, client B retrieves the file for read-only access. It should be appreciated that the file, as retrieved by client B, is in its original state, since the modifications made by client A have not yet been written back to the server. The earlier modifications made by client A to the file are not apparent to client B and may have potentially disastrous effects, depending of course, upon the particular application running at client B.
A similar problem arises if client A retrieves a file for read-only access. At some later time client B retrieves the file with read-write access and makes modifications to the file. These modifications are transparent to client A, which is still operating with the original file contents in its cache.
It can be appreciated from the foregoing description that some type of file or resource management system must be implemented at the server to maintain the integrity of the files centrally stored at the server location. Indeed, some systems have solved this problem by providing an absolute lock at the file server, permitting only one client (having read-write authorization) access to a file at any given time. That one client must, therefore, write the file back to the server before another client is allowed to access the file. The problem, however, created in this type of system is that a second client requesting access to a locked file has no indication of when the file will be released by the client having present access to the file. Accordingly, it is further desired to provide a system having a way of forcing a client to release control of a file that it has retrieved into its local cache.
This problem is broadly addressed by U.S. Pat. No. 4,887,204 ('204 patent) to Johnson et al., and assigned to International Business Machines Corporation (IBM.RTM.). The '204 patent solves this problem by providing a plurality of "synchronization modes". Specifically, three synchronization modes are provided. The system of the '204 patent operates in a first synchronization mode (A.sub.-- synch mode) when a file is being accessed by a single client with read-write authorization. The system operates in a second synchronization mode (Read.sub.-- only mode) when one or more clients have accessed a file, each with read-only authorization. Finally, the system operates in a third synchronization mode (Full.sub.-- synch mode) when multiple clients have access to a common file, and at least one client has retrieved the file with read-write authorization.
In either the A.sub.-- synch or Read.sub.-- only modes mentioned above, the file is transmitted from the server into the local cache of each client having access to that file. In the Full.sub.-- synch mode, however, the shared file is maintained at the server, so that any read or write operation must take place through transfers over the network. Although operations in this mode necessarily degrade the network performance, the mode nevertheless provides an effective way of maintaining file integrity while allowing multiple client file access.
The '204 patent further describes the dynamics of the synchronization modes as multiple clients request and release access to various files in the network environment. For example, if client A is the first client to access a file from the server and requests read-write access to that file, then that file is transferred to client A's local cache in the A.sub.-- synch mode. If at some later time client B requests the same file for read-only access, then the server requests client A to change to the full-synchronization mode (See col. 21 lines 19-22). Client A responds by flushing that file from its local cache and writing back to the server any portions of the file that were changed by client A. At this point, both client A and client B must access the file, which will be maintained at the server, over the network link. If at some later time client A has completed operations on the file, it instructs the server that it is finished. The file's synchronization mode is then changed to Read.sub.-- only, and the file is transferred from the server to client B's local cache. Subsequent reads from client B then can be accommodated locally, without requiring transfers over the network link.
The above solution, while workable, has certain drawbacks and deficiencies. More specifically, the '204 patent addresses the shared resource management problem in the broad sense by assuming, for purposes of that invention, free two-way communication between the server and clients. Indeed, columns 20-22 discuss changing from A.sub.-- synch to Full.sub.-- synch and from Read.sub.-- only to Full.sub.-- synch synchronization modes. In each of these instances, it is assumed that the server has direct command control over each client (See col. 21, lines 19-21 and col. 22 lines 12-15), whereby the server may direct a client to release a file residing in its local cache. The file management as taught by the '204 patent, wherein a file lock at a client may be broken, is often referred to as an opportunistic lock.
However, present systems are known that employ a "ping pong," or request/response, transfer protocol of information exchange between client and server. In such systems, command sequences are initiated by the client, whereby a client submits a command or request to the server and then awaits the server's response. If a client has not initiated a request of the server, it has no reason to monitor the network link and may therefore ignore commands initiated by the server. Accordingly, the server generally cannot unilaterally command a client to release its control of a particular file.
To more particularly illustrate this problem, suppose client A is the first client to request access from a file stored at the server, and requests to have such access with read-write authorization. Since no other client has contemporaneous access to this file, the file is transferred into client A's local cache. Later, client B requests access to the same file from the server. The server must then signal client A to release its exclusive access over the file and flush its local cache. However, in a system having a typical request/response transfer protocol, client A will not be listening to the network link and, thus, will not know of client B's desire to access the file. As a result, the operation at client B will either be suspended, or at least unduly slowed while client B awaits to receive the file from the server.
It can be appreciated from the foregoing discussion, that a need exists for a system to provide opportunistic access to a file in a system of the type having a request/response transfer protocol, whereby informational exchanges may be instituted upon a client's request, even if another client is presently accessing the same file.